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ESCORT: A DATA ACQUISITION AND DISPLAY SYSTEM TO SUPPORT RESEARCH TESTING 

Robert L. Miller 
NASA - Lewis Research Center 


ABSTRACT 

Lewis Research Center of NASA has 
been involved in the design and 
implementation of data acquisition 
systems to serve its many research 
testing facilities for about 25 years. 
Initially, data acquisition and 
recording were handled as separate 
functions from processing. With the 
advent of the minicomputer and 
microcomputer, these functions have been 
combined to provide rapidly updated 
displays in engineering units of 
select-d data. This allows the 
researchei to expedite testing and 
acquire data in the specific areas of 
interest. Lewis' approach to system 
design tal":s into account maximum 
utilization of equipment, backup 
capability, off-the-shelf system 
availability, modula approach to both 
hardware and software, and provision for 
program development and checkout 
independent of the system on which it is 
to be used . 

The system to be described, known 
as Escort, is currently being installed 
at many of the small to medium-sized 
research test facilities at Lewis. 
Primarily designed to acquire data at 
steady-state test conditions, the system 
can also monitor slow transients such as 
.those generated in moving to a new test 
condition . 

The system configuration makes use 
of a microcomputer at the test site 
which acts as a communications 
multiplexer between the measurement and 
display devices and a centrally located 
minicomputer. A variety of measurement 
and display devices are supported using 
a modular approach. This allows each 
system to be configured with the proper 
combination of devices to meet the 
specific test requirements, while still 
leaving the option to add special 
interfaces when needed. 

Centralization of the minicomputer 
improves utilization through sharing. 

The creation of a pool of minis to 
provide data acquisition and display 
services to a variable number of running 
tests offers other important advantages 
which will be discussed. 


THE ENVIRONMENT 

Lewis Research Center of the 
National Aeronautics and Space 
Administration is engaged in the 
development and testing of a wide 
variety of hardware . Most of this is in 
some way related to propulsion or power 
systems for aeronautics, space, or 
ground based applications. The 
environment consists of large numbers of 
research testing facilities ranging in 
size from the 10x10 foot supersonic wind 
tunnel down to the life testing of 
batteries . 

In conducting thir. experimental 
testing, large numbers of data 
measurements such as pressures, 
temperatures, forces, flows, speeds, 
voltages, and currents must be made and 
entered into equations in order to 
determine performance. Since this is a 
research environment, relatively high 
accuracy is usually required. Both 
static and dynamic measui cmer.ts are 
often necessary. 

Because of the inherent differences 
in the measurement technique, analysis, 
and presentation of results of static 
and dynamic data, separate data 
acquisition and processing systems have 
usually been designed to perform these 
two functions. The system to be 
described addresses the problem of 
acquiring and processing static data 
measurements for the on-line analysis of 
research experiments. 

The research test facilities at 
Lewis are scattered over a 340 acre 
area. In most cases, provision has been 
made to run special-purpose cables 
underground to provide for data 
communications to a central location. 

The concept of centralized data 
recording and processing has been 
generally followed for nearly 25 years, 
with special-purpose on-site systems 
installed only when necessary. The 
objective was to standardize hardware 
and software support to minimize costs 
in both manpower and hardware, and to 
achieve a high degree of reliability. 
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THE PROBLEM AND OBJECTIVES 

The basic problem of supporting a 
typical research test has not changed 
significantly over the years. What has 
changed dramatically, are the possible 
solutions to the problem created by the 
state-of-the-art explosion in the 
computer field. These changes have made 
it possible for the research engineer to 
have a much more intimate and detailed 
understanding of the experiment during a 
test. Functions previously requiring a 
large scale computer for support can now 
be performed using mini and micro 
computers . 

It was obvious, at the beginning of 
the minicomputer revolution, that the 
best technical solution was to install a 
minicomputer-based system at each test 
facility. The system was configured and 
programmed to match the individual 
requirements of each location, and 
therefore able to best accomplish that 
specific task. The user was expected to 
provide whatever software might be 
required over and above some standard 
modules which were supplied. 

A number of things were learned as 
the result of installing several systems 
using this philosophy. Hardware 
configurations tended to be customized, 
and therefore difficult to maintain. 
Althouqh initially the users "ore 
enthusiastic about becoming ivolved in 
programming a computer, this eventually 
resulted in their not being available 
for the job for which they were 
hired--to conduct research tests and 
develop hardware in their field. 
Documentation of both hardware and 
software was difficult to maintain in a 
form that another person could follow if 
necessary. Pressure soon developed to 
provide software support from a central 
group of programmers, or to hire a 
programmer for each machine. 

As a result of these developments, 
a new look was taken at how to provide 
adequate data acquisition and processing 
services for a large number of research 
test facilities, taking into account 
both the technical and the management 
problems involved. 

Keeping this in mind as a main 
objective, the following system design 
criteria were established: 


Locate Minicomputers Centrally 

This will permit assignment to 
tasks on an as-needed basis. Computing 
power can be matched to research 
requirements through a hierarchy of 
minicomputers having several levels of 
power and speed, including networking to 
large processors where necessary. 

Configuration Flexibi 1 ity 

Design a base hardware and software 
package along with an assortment of 
pre-tested options to meet the majority 
of the known requirements, leaving the 
option for a limited number of unique 
functions . 

Off The Shelf Availability 

A major problem in the development 
of custom systems had been the one to 
two year lead time necessary for total 
procurement and implementation . The 
goal is to be able to provide a working 
data acquisition and display system two 
or three weeks following requirements 
definitions . 

Minimize Experiment -Unique Custom 
Programming 

Provide user-oriented tools to 
accomplish the tasks which make 
experiment-unique programming necessary. 

Minimi ze Down t i me 

Utilize quick-change, standard 
modules in the design, backed up by 
available spares, and a thorough field 
maintenance training program. 

Develop And Pre-Test All Hardware And 
Software 

Create a mock test facility in the 
central area, to make possible the 
development and testing of all hardware 
and software modules, before installing 
in a research test facility. 

Stress H uman Engineering 

Employ current computer technology 
to eliminate the need for the user to be 
a "computer expert". 
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THE APPROACH 

With the above criteria and 
constraints in mind, a system called 
Escort was configured which allows all 
of the input-output devices necessary at 
the test facility to be connected to a 
centrally located minicomputer via a few 
wire pairs. A microcomputer at t..e test 
facility serves as a communications 
multiplexer, sorting all messages 
between each of the devices and the 
central minicomputer (Fig. 1). 



Fig. 1. Escort Configuration 


This is known as a Remote 
Acquisition Micro Processor (RAMP) . At 
the central computing area, the wire 
pairs from the microcomputer are 
terminated in a patch panel, where they 
can be jumpered to any mini in the pool. 
The minis in the pool are hardware and 
software compatible between machines of 
the same level, and upward compatible 
with machines of a higher level of 
computing power, speed, or capacity. 

The total data acquisition, 
archival recording, and processing path 
is shown in Figure 2. 


A*CM! VM. 



Here, the Escort system, consisting 
of the RAMP and central minicomputer, is 
shown as it is used in conjunction with 
two other major elements which support 
the research testing. The Data 
Collector is a minicomputer based system 
which provides archival recording for a 
large number of Escort and other data 
acquisition systems. It also provides a 
communication link to a large central 
processor . 


The large-scale central processor 
is a time-sharing machine capable of 
providing complex on-line calculations 
back to the test facility. Depending 
upon the nature of the research test, 
and the complexity of the analysis, this 
machine may be used to augment the 
on-line computing support contributed by 
Escort. It also does all of the 
computation necessary for the 
preparation of research reports, 
including preparation of graphics and 
microfilm. 

Compact 



TCRMin O.V. 

Fig. 3. RAMP Configuration 
RAMP Conf iguration 


Fig. 2. 


Total Processing Path 


The RAMP serves as a communications 
multiplexer to devices which communicate 










4 


with the experiment and the 
experimentor . All of this information 
is relayed back and forth from the 
cenf'il minicomputer. Figure 3 shows 
the J1P , wich devices which talk with 
the experiment on the top, and devices 
which talk with the experimentor on the 
bottom. 

Experiment Comnun icat ion will be 
discussed first. In typical test 
facilities, the basic input device is 
the analog multiplexer and 
analog-to-digital converter (MUX-A/D) 
which provides the means for measuring 
large numbers of analog signals in the 
volt or millivolt range. Thermocouples, 
strain gages, pressure transducers, and 
any other instrumentation, which 
generate a signal in the form of an 
analog voltage, are interfaced to the 
system through an analog MUX-A/D. Most 
data is acquired through this path. 

A second method for introducing 
data into the system is through pressure 
scanning switches. These are widely 
used for pressure measurements because 
they are a less expensive alternative to 
using a pressure transducer for every 
pressure channel. They make use of a 
mechanical pressure switch to connect a 
single tranducer sequentially to a 
number of pressures to be measured. 
Another microcomputer controls this 
scanning and the temporary storage of 
measurements . 

The most recent sample of all 
pressures measured is transferred from 
the pressure scanner micro to the RAMP 
micro on request. 

A third method for introducing data 
into the system is through contact 
closures. The standard RAMP senses up 
to 24 contact closure inputs. Since the 
same mechanism is used for function 
switches (discussed later) and contact 
closure sensing, it is actually the sum 
of these which cannot exceed 24 . These 
numbers apply only to a standard system, 
however, and could be increased to meet 
special requirements. 

Contact outputs are used for 
communication both to the experiment and 
the experimentor. They can be used for 
such purposes as stopping the experiment 
when an unsafe or out-of-range condition 
exists. They may also be used to sound 


an alarm to alert an operator to a 
similar, or less serious condition. 

Operator Communication peripherals 
shown at the bottom of Figure 3, are as 
follows: (1) Alpha-Numeric CRT; 

(2) digital numerical displays; 

(3) function switches; (4) number 
entry panel; (5) Graphic CRT Display; 
and (6) hard copy printer and keyboard. 

The alpha-numeric display is the 
primary monitoring device used in the 
test facility. It is often used with a 
buffered printer to allow the contents 
of the screen to be printed without 
interfering significantly with the 
dynamic update of the screen . Two of 
these devices are sometimes used in a 
typical installation. One is used to 
monitor the experiment, while the other 
is used to monitor the test facility 
which sets the test conditions. 

Generally up to 40 parameters with 
labels can be displayed and dynamically 
updated on each screen . 

A graphic display, with or without 
hardcopy, can also be used to create a 
continuously updated performance curve. 
Bar charts oi multiple line graphs are 
possible . 

Another method of continuous 
monitoring of test facility parameters 
is by means of digital numerical 
displays, which are numbers formed by 
light-emitting diodes. These are 
generally used in applications where a 
few specific parameters must be 
continuously displayed and updated at 
various locations in a control room for 
operator use. Up to 15 five-digit 
numbers (five digits, sign, and decimal 
point) may be displayed in this way in a 
standard system. 

Functions switches arc oimply 
pushbutton switches, each cf which has 
been assigned a specific function. The 
functions assigned these switches are 
implemented by means of software and so 
can differ between test facilities, 
conforming to specific requirements. 
Function switches are used to initiate 
system actions which must be taken 
repeatedly in the typical operation of a 
test facility. Some common usages 
are: "Record a Data Point", "Make a 

Hard Copy of CRT Display", "Display a 
Different Set of CRT Parameters", etc. 
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Up to 24 function switches can be 
incorporated in a standard system. 
However, the sum of function switches 
plus contact closure inputs cannot 
exceed 24, as mentioned previously. 

The number entry panel provides a 
mechanism for entering numbers into the 
system for specific purposes. It is 
used in conjunction with the function 
panel for initiating functions which 
have a number associated with them. For 
example, "Display Parameter List Number 
Three on the CRT.” A number up to 256 
can be entered by means of a 
calculator-type number keyboard and 
display register. 

The Escort terminal shown on Figure 
3 is interfaced directly to the central 
minicomputer. It is used for facility 
interaction with the central 
minicomputer, for logging events, and 
for error reporting. Typical uses for 
this device might be to change limits in 
a limit checking calculation or to 
remove certain parameters from an 
averaging calculation. 

RAMP Operation 

The RAMP can acquire data from all 
of the above instruments and service the 
monitoring devices and control panel . 

It both sends and receives command and 
data messages to and from the 
minicomputer. The RAMP is, with one 
exception, a slave to the minicomputer. 
All of its actions are initiated by 
commands embedded in messages from the 
mini. As an example, the mini may 
request a scan of the multiplexed A/D 
channels. The RAMP would perform the 
scan using a pre-stored address pattern 
and then transmit the data to the mini. 
The function switches, however, are 
handled in a unique way. The RAMP 
senses the status of all the contacts 
and responds to each change by sending a 
message to the mini containing the 
current status of all the contacts plus 
the value stored in the number entry 
panel . 

The RAMP makes both longitudinal 
and vertical checks on messages to 
detect any communication errors caused 
by noise on the line connecting the two 
processors, and requests a repeat 
transmission if any are present. It 
continues to request repeats until the 


transmission i s validated, or until it 
is clear that the line is defective (at 
present this is concluded after six 
successive failures) . The minicomputer 
makes similar checks at its end. 

Character data sent to the displays 
may be either verified or not verified 
depending upon requirements. When the 
application is such that a single error 
is not tolerable (e.g., output to a 
programmable controller) , the verified 
mode is used. Data in error is not sent 
to the display device and a 
retransmission from the mini is 
requested. Somewhat faster throughput 
may be realized in the non-verified 
mode. The communication lines have a 
very low error rate and errors are 
corrected on the next update. If 
updates are occurring frequently (e.g., 
once per second) , it is faster to let 
the problem clear itself with a new 
update than to make an effort to 
retransmit the old data. 

The RAMP contains a "watchdog 
timer" which notifies the facility of a 
possible failure in the minicomputer or 
communication line wherever it does not 
receive any requests for data within a 
selectable interval (nominally 15 
seconds) . It uses contact output number 
20 for this purpose. 

Central Minicomputer Con f iguration 

There are three different levels of 
support pr 'ided by the central 
minicomputers, depending upon the 
requirements of the particular test. 
These are designated Escort I , 

Escort II, and Escort Multi-Application. 
The basic chracteristics of these three 
machines follow. All use a 16 bit 
general purpose minicomputer. 

Escort I operates under a real-time 
executive utilizing a foreground/ 
background mode, supported by 32K words 
of magnetic core storage and a 2.5 
megabyte disc. It is dedicated to one 
test facility at a time. 

Escort II operates under a 
multi-task real-time executive supported 
by 64K words of magnetic core storage, 
two 2.5 megabyte discs, and floating 
point hardware. It is dedicated to one 
test facility at a time. 
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Escort M/A operates under a 
multi-task real-time executive supported 
by 96K words of magnetic core storage, 
three 2.5 megabyte discs, and floating 
point hardware. It serves multiple test 
facilities at a time. 

Assignment of a research test to a 
particular machine follows these general 
criteria. Tests which require on-line 
display support with less than 200 
channels of data are assigned to 
Escort I. Those which require on-line 
display support and have more than 200 
channels use Escort II. Tests which do 
not require on-line display support, 
such as life tests, use the Escort M/A. 

SERVICES PROVIDED 

Escort provides the researcher and 
test engineer with a wide variety of 
services ranging from data recording to 
facility monitoring and the playback of 
essential test parameters. This section 
describes those options which arc an 
integral part of the system and can be 
supplied "off the shelf". However, 
Escort may be modified, where necessary, 
to fulfill requirements not covered by 
the standard options. 

Data Record in g 

Escort acquires data in a burst 
mode at one-second intervals in order to 
provide a continuous update of monitors 
and playback services. Normally this 
data is processed and then discarded, 
but it can be permanently recorded. A 
"reading" can be recorded either 
manually by be pressing a pushbutton on 
Escort's function panel, or 
automatically through the use of a 
schedule entered into Escort's clock 
facility. It is also possible to invoke 
data recording through user-supplied 
contact closure or when some signal 
exceeds a pre-established threshold. 

II i story F ile 

dome pc.i Lion of the data acquired 
hv Escort can be temporarily stored in a 
history Fi^c for later reference. This 
file is especially useful in experiments 
where there may be unpredictable 
failures or other special events which 
can only be analyzed if there exists 
detailed information on the conditions 
proceeding them. The file is also 


useful, however, for referring back to 
previous conditions or for verifying the 
reproducibility of the data. Thus the 
History File can provide a kind of slow 
motion "instant replay" of data written 
on it . 

The History File can be thought of 
as a simple ring buffer in which the 
oldest data is continually being 
overwritten by new data. The length of 
time that data is stored is determined 
by the size of the ring, the size of a 
scan of data, and how often data is 
written into the file. 

The History File can be configured 
so that it is updated either by pressing 
a button on the control panel or by 
simply specifying that every "Nth" scan 
be recorded. In this case, the 
occurrence of the special event must 
freeze the file to prevent the important 
information from being overwritten. The 
system can recognize an event from 
contact closure, a limit violation, or 
the pressing of a button on the front 
panel. Some "past history" or data 
following the event can be included by 
specifying that the "freeze" should 
occur so many scans after the event 
trigger . 

E xperiment Data Monitoring 

Escort provides an alpha-numeric 
CRT for experiment data monitoring. A 
display editor allows the user to design 
his own display format. The information 
presented on this device can be data in 
millivolts, data in engineering units, 
or derived quantities. The acquisition 
time and date, barometer, display 
number, test ident i f icat ion , and an 
indication of millivolts or engineering 
units are included with each display for 
a reference. Many experiments and tests 
contain more information than can be 
placed on one or even two CRT screens. 
Frequently it is desirable to see 
different subsets of information at 
different times. Escort supports this 
need by providing up to Is predefined 
display pages which can be selected by 
entering a number into the number entry 
panel anil then pushing the DISPLAY 
function button. If another pattern is 
selected and it is desired to return to 
the previous one, it can be recovered 
simply by hitting the LAST DISPLAY 
button. In this way the user can 
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alternate between two patterns without 
reentering the pattern nur.ibers or can 
easily work between a primary pattern 
and several alternatives. 


Facility 

Data Monitoring 

Escort provides four aids to 
operation and monitoring of the 
faci 1 ity : 

1 . 

Operator displays. 

2 . 

Limit Checking. 

3. 

Contact closure programs 

4 . 

Operation Log. 


A separate display capability has 
been dedicated to the playback of 
important operations parameters as 
distinct from research data. The 
parameters can be either measured or 
derived and can be represented in either 
millivolts or engineering units. The 
operator's displays are not pushbutton 
selectable as is the research CRT 
display. The update rate may be higher 
than that of the research monitor. The 
display device may be a set of up to 15 
discrete digital panel meters similar to 
those found on calculators, or 
alternately an alpha-numeric CRT similar 
to the experiment CRT. The advantage of 
the discrete meters is that individual 
parameters may be displayed where they 
are the most convenient whereas a CRT is 
able to present more information and can 
include labels and explanatory comments. 

Escort can be used to automatically 
monitor a number of signals which must 
be kept within predefined limits. '’’he 
values of the limits, either upper, 
lower, or window, can be entered in 
engineering units. The system will then 
compare the signals against their limits 
every time data is acquired. If one is 
out of limits a prescribed number of 
times in a row (from 1 to 15) , Escort 
will notify the operator and possibly 
take some emergency action. Three types 
of alarms are provided: (1) A typeout 

on the facility log of the time, word 
number and limit which was exceeded; 

(2) A "summation" contact closure which 
is activated when any limit is violated 
and can be used to drive an 
out-of-limits audible or visual alarm; 
and (3) Up to 14 individual contact 


closures, each of which can be assigned 
to one or more channels and which can be 
used to drive alarm panels. Two sets of 
limits can be assigned to a channel, one 
which invokes the above warnings and one 
which also takes some action such as 
shutting down the facility and freezing 
the history file. 

RESULTS 

Although all the features of the 
Escort concept have not been fully 
developed at this time, 12 RAMPS have 
been installed at test facilities and 
are operational . Considerable 
experience has been gained in adapting 
the modular approach to a wide variety 
of research tests, and in training both 
professionals and technicians to use the 
system. As might be expected, this 
experience has resulted in some minor 
modifications to certain features in the 
system, but the basic concepts have 
proven to be workable. Especially 
gratifying is the fact that all of the 
initial objectives appear to have been 
attained . 

User Reaction and Observations 

The user community is comprised of 
a wide variety of scientists and 
technicians, some of whom have used 
computerized systems, and some who have 
not. Those who have been using 
computers in a hands-on mode feel that 
Escort is limited in its capabilities, 
particularly with regard to what can be 
done to program the system for specific 
calculations or functions. Those who 
have no experience with computers find 
Escort to be a valuable tool in running 
experiments because it allows them to 
see and monitor variables which they 
could not see previously. 

A major concern on the part of many 
users, prior to having any experience 
with the system, had to do with the 
limitations of the communication line 
between the micro and the central mini. 
The update rate of the system is 
presently limited by the 10K bit rate on 
this line. Experience with the present 
users and tests has shown that an update 
of all displayed data is desired at 
intervals of once every second or two. 
Although some of the installations are 
coming close to this rate, many are 
taking about twice this long. Analysis 
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of the total system update limitations 
has shown that although the 
communications line could be driven at 
twice the present speed, the method by 
which the data enters the minicomputer 
would have to be changed to take full 
advantage of the speed. Both of these 
steps are being considered if the update 
rate becomes a serious problem. 

The other major concern, especially 
on the part of experienced computer 
users, is the fact that the minicomputer 
has been removed from the test facility, 
and is therefore not as accessible to 
custom program a job. This is probably 
the most controversial aspect of the 
Escort concept, and one which deserves 
some discussion at this point. 

The decision to move the 
minicomputer to a central location was 
based on management concerns and 
problems more than on technical reasons. 
Most system designs are the result of 
compromises between technical 
requirements and marketing, 
manufacturing, servicing, and 
programming support requirements. The 
constraints placed on the design of 
Escort resulted in compromises between 
technical requirements and management 
and support requirements. It was well 
recognized that we were dealing with a 
broad spectrum of users within a 
scientific community, and that the 
system supplied would have to meet the 
minimum requirements of most of the 
jobs. It was also recognized that many 
of the users would not be able to 
provide programming support for their 
system, and that this would have to be 
supplied by a central programming group 
which was severely limited in manpower. 
Experience with custom local systems 
previously showed that although there 
was some interest in users doing their 
own programming, frequent complaints 
from their management indicated that the 
user was not spending his time doing the 
work for which he was hired. The 
responsibility for supplying programming 
for the system often reverted to the 
central group, at which time it was 
discovered that the documentation was in 
a chaotic state, and most work had to be 
redone from scratch. This resulted in 
very poor utilization of the central 
programmers. Since most of the 
programming support would ultimately be 
done by the central group, it was 


decided that the system design should 
make good use of their time and efforts. 
The philosophy was adopted that Escort 
systems should have full hardware and 
sof re support from the time that the 
system is installed until it is removed 
from setv.ee to be used in another 
application. With this concept, the 
researcher can use the system as a data 
acquisition and display tool without 
being burdened with the task of learning 
programming or understanding the 
internal workings of computers. 

As a result of concentrating the 
minis in one area, the central 
programming group spends its time 
working rather than travelling to remote 
locations. Documentation is well 
maintained, and there is good 
consistency with regard to how jobs are 
programmed. It is much easier for one 
programmer to take over the work of 
another if necessary. Because of a 
number of similar machines in the 
central area, program development rarely 
interferes with running a test facility. 
Also, if a test facility runs into 
difficulty, there is a programmer 
usually available to assist. 

Test Facility Simulator 

Early in the development phase of 
Escort it was recognized that a test 
facility simulator would be needed in 
the central area to develop and check 
out both hardware and software. This 
eliminated the difficulties related to 
trying to debug problems between two 
widely separated parts of the system. 

In addition, developmental work could 
proceed prior to, and during, the 
installation of a new system. This 
concept turned out to be so advantageous 
that a second simulator was installed. 

Although the simulators are busy 
most of the time on software 
development, they have also turned out 
to be valuable in training new users. 
Demonstrations can be set up in a 
controlled environment, and the user can 
see what happens at both ends. 

Installed Systems 

Twelve RAMP systems are currently 
installed in the field, with new systems 
going in at the rate of about one a 
month. Research tests being conducted 
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using these systems vary widely, and 
make use of all three levels of support 
available under Escort. Following is a 
list of tests being conducted. 

Full scale jet engine 

High temp, high pressure compressor 

Jet engine combustor 

Diesel engine 

Gas turbine automobile engine 
Ion thruster 
Vertical lift fan 
Anechoic chamber analyzer 
High power gas laser 
Solar radiation 
Photovoltaic array 
Shuttle seal 

Improved Implementation Times 

One of the objectives in going to 
the Escort concept was to reduce the 
time required to provide a system to a 
new user. With custom-specified systems 
installed at the test facility, between 
one and two years lead time had been our 
experience . 

Because of the modular design of 
the RAMP, it can easily and quickly be 
configured to meet most of the 
requirements which are encountered. 

Since the desiqn incorporates a standard 
set of options for all systems, a 
sufficient number of modules of all 
types can be kept on hand to provide for 
both new installations and spare parts. 

Because of the flexibility in the 
central mini area to assign computers on 
an as-needed basis, it isn't always 
necessary to buy a new computer when a 
new job comes in. There is a sufficient 
number of computers in the pool to 
handle a practical worst-case running 
schedule of the test facilities, while 
still not requiring a computer for each 


test facility having a RAMP. Some tests 
are run on different shifts, which also 
aids sharing. 

As a result, the objective of being 
able to install a working system in a 
few weeks from the time of requirements 
definition has become a reality. This 
was proven in a particular case when a 
researcher found a need to quickly 
acquire data on seals to be used in the 
Space Shuttle. The system was 
configured, installed, some small amount 
of custom software developed and 
combined with standard software modules, 
and made operational three weeks from 
the time that the job was defined. Not 
only was the job done quickly, but a new 
phenomenon in choked flows was observed 
which had not been seen with the 
previous data recording system. 

CONCLUSION 

Considering both the technical and 
management problems related to providing 
on-line data acquisition and display 
services for a large number and variety 
of research tests, the Escort concept 
has combined minicomputer and 
microcomputer in a unique way to meet 
this objective. Neither system 
performance in terms of speed or 
technical characteristics are worthy of 
being reported, but the ability to solve 
a data acquisition and display problem 
quickly and with a minimum of effort is 
worth noting. 

Escort is still under development, 
particularly in the areas of graphics 
support and direct digital communication 
to special purpose instruments. It is 
expected that ultimately upwards of 40 
or more test facilities will be served 
by Escort systems at the center. 



